Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-21 / tips1290.zip / TIPS1211.ASC < prev

Wrap

Text File | 1991-02-02 | 95KB | 2,143 lines

Tips by Craig S. Stevenson, Sysop, The Bertha BBS From: The Bertha BBS (218)-924-2060 (Node 1 - USR Dual-Standard) 16,000+ Files On-Line (DesqView, Windows, PCX Clip-Art, Etc.) FREE - First Call Access! (Upload/Download Byte Ratios Apply) Date: December 11, 1990 Availability: The current ASCII version of TIPS is available to subscribers of The Bertha BBS. Disclaimer: Use the tips at your own risk! I have tried to be accurate in my diagnosis of problems and their solutions. However, it is impossible to know everything about your machine. These tips worked on my machines, they may not work on yours due to some unforeseen differences. Neither I, nor The Bertha BBS will be held responsible for damages done by anything you do to your machine. Distribution: This file may be distributed on BBS's as long as it is not modified in any way. Support: If you find the TIPS helpful, you may show your appreciation by making a small contribution of $10.00. This helps to defray the costs of maintaining and distributing the TIPS file. You may send a check or money order to: Craig S. Stevenson, Sysop The Bertha BBS P.O. Box 297 Bertha, MN 56437-0297 If you are a subscriber to The Bertha BBS, your support has already been given. Thank you very much. Contributors: Bill Earnest - (Future Domain SCSI Controller Information) The people listed above have contributed valuable information to supplement existing tips. If you have any information regarding the information contained in any of the tips, please feel free to contact me at the number listed above. ══════════════════════════════════════════════════════════════════════════════ What's new in TIPS1215: The following is a list of hardware and software used to develop TIPS: HARDWARE SOFTWARE DTC 6280 ESDI Disk Controller ADCACHE Version 1.20 DTC 5280 MFM Disk Controller Automenu 4.5, 4.7 DTC 7280 MFM Disk Controller CardX 8.3, 8.9 DTC 7282 RLL Disk Controller Check-It DTK 386-25 (Cache) DAC Accounting 4.0, 4.1 Hayes V.42 Modem DAC Payroll 4.0, 4.1 IBM Color Printer DesqView 2.25, 2.26, 2.31 IBM Proprinter II Disk Technician Advanced IBM Proprinter XL24 Doorway 2.05, 2.06(Beta), 2.11 Imprimis 94205-51 Hard Drive DSZ 4-11, 6-26, 11-19 IRWIN IR-445 Tape Backup Flash News 3.0 Lantastic Ethernet Card Generic Cadd Level 3, CADD 5.0 Lantastic Voice Card Lantastic NOS 3.0, 3.02 Ethernet Maxtor XT-4380E Hard Drive Lotus 1-2-3 Version 2.2, 3.1 Microscience HH-1090 Hard Drive Manifest 1.00, 1.01 Microscience HH-1050 Hard Drive MS-Dos 3.3, 4.0 NEC Multisync 3D Monitor New Print Shop Panasonic KX-P4455 Laser New Print Shop Companion Panasonic KX-P1124 Printer Novell Advanced Netware 2.15 Roland DXY-1200 Plotter PCTools Deluxe 5.5, 6.0 Seagate ST-225 Hard Drive PFS: Professional Write 2.1 Seagate ST-238 Hard Drive Publish-It 1.1, 1.2 Seagate ST-251 Hard Drive QEMM 4.23, 5.00, 5.11 Seagate ST-4182E Hard Drive Qmodem 4.1b, 4.2, 4.2A, 4.2B, 4.2C Seiko Smart Label Printer RBBS-PC 17.3, 17.3A, 17.3B Summasketch MM-1201 Tablet Reconfig 3.1 Toshiba XM-3201B CD-ROM SHEZ 5.7, 5.8, 5.9 USR Courier Dual Standard Smart Label Printer Software USR Courier HST 14400 Super PC-Kwik 3.53 Video Seven VRAM 512 Video Card TAME 2.30, 2.41, 2.44, 2.50 Zenith Z159-8 THEDRAW 3.30 Zenith Z286-8 UPDN 6.6C Zenith Z286-12 Windows 3.0 Zenith Z386-16 X00.SYS Version 1.22, 1.23H, 1.24 Zenith Turbosport 386 ZDOS 3.3+, 4.01 Zenith Z386-25 Zenith ZCM-1390 Monitor Zenith ZCM-1490 Monitor Zenith ZCM-1492 Monitor ══════════════════════════════════════════════════════════════════════════════ ┌───────────┐ │ TIP INDEX │ └───────────┘ ══════════════════════════════════════════════════════════════════════════════ Category Tip# Problem Or Topic ------------- ---- ------------------------------------------------------- QEMM/DesqView 1 Repeated system hangs when using DesqView. QEMM/DesqView 2 High speed communications causing hangs within DV. QEMM/DesqView 3 Print screen causing hangs in DesqView 2.26. QEMM/DesqView 4 System hangs when using PCTools Deluxe V6.0 in DV. QEMM/DesqView 5 Getting a caching program to work with DesqView. QEMM/DesqView 6 Acquiring more high ram. QEMM/DesqView 7 Communications program causing system slowdown in DV. QEMM/DesqView 8 Increasing DesqView window sizes. (Using Zenith DOS) QEMM/DesqView 9 Larger DV windows and more high ram. (Zenith only) QEMM/DesqView 10 Intermittent DesqView problems. QEMM/DesqView 11 "Drive x Not Ready" error message from hard disk drive. QEMM/DesqView 12 System hangs and file corruption. QEMM/DesqView 13 Caching problems when using DesqView. QEMM/DesqView 14 CD-ROM problems when using DesqView. QEMM/DesqView 15 Problems when running RBBS-PC under DesqView. QEMM/DesqView 16 System hangs after doing floppy access. Zenith 1 System hangs when doing a warm boot with QEMM 5.0. Zenith 2 Slow video after installing QEMM 5.0. Zenith 3 Increasing DesqView window size for applications. Zenith 4 "Unable to read sector" error message from PCTools. Zenith 5 "Error, Keyboard Not Connected" error message. Zenith 6 Slow hard drive access on Zenith Turbosport. Zenith 7 Problems interfacing the Irwin 445A tape backup unit. RBBS-PC 1 DV applications interfering with user communications. RBBS-PC 2 Poor performance of RBBS when using multiple nodes. RBBS-PC 3 Optimizing performance with X00.SYS. RBBS-PC 4 Connection problems for callers. RBBS-PC 5 Zmodem giving error messages during uploads/downloads. Communications 1 MNP-5 modem connection problems. Communications 2 Slow download speeds when using 2400 baud MNP-5 modems. Communications 3 Slow download speeds from some USR HST boards. Communications 4 DSZ/Zmodem will not work on my system. Communications 5 Garbage on screen with MNP-5 modem. Communications 6 Unable to attain a V.42bis connection with USR modem. Doorway 1 Screen problems when using Doorway under DesqView. Doorway 2 Typing during screen update produces garbage on screen. Doorway 3 Some programs refuse to run remotely with Doorway. Doorway 4 PC Shell won't display proper characters under Doorway. Qmodem 1 Qmodem 4.2 or 4.2A will not dial phone automatically. Qmodem 2 ANSI codes appear randomly on screen with Qmodem 4.2. Qmodem 3 Random characters lost during BBS sessions. Reconfig/Automenu 1 Reconfig not working properly when caching enabled. Reconfig/Automenu 2 Using write caching with Automenu and Reconfig. Hardware 1 Floppy/Hard drives not working properly. Hardware 2 Two LPT ports will not work correctly on one machine. Hardware 3 Garbled characters when using an IBM color printer. Windows 1 Windows 3.0 will not run when using Disk Manager. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌───────────────┐ │ KEYWORD INDEX │ └───────────────┘ ══════════════════════════════════════════════════════════════════════════════ Keyword Mentioned In TIPS: ---------- ---------------------------------------------------------------- Desqview QEMM/DesqView #1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 Zenith #3 RBBS-PC #1, 2, 5 Doorway #1, DSZ QEMM QMODEM X00 Zenith ══════════════════════════════════════════════════════════════════════════════ ┌───────────────┐ │ QEMM/DesqView │ └───────────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 1 │ └───────────────────────┘ PROBLEM: Repeated system hangs when using DesqView. SYMPTOMS: System will hang intermittently and with no warning. SOLUTION: Check the setting of "Manage Printer Contention" in the DesqView Setup area. Numerous hangs are caused by having this set to "Y". Set it to "N". You must make sure not to have two applications printing at the same time. NOTE 1: The solution that I use for this problem is to use a buffer on the printer. Mine is 512K. That way I can print and the buffer takes all the data. Then I can close the window and print something else from another application immediately. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 2 │ └───────────────────────┘ PROBLEM: System hangs when using high speed communications within DesqView. SYMPTOMS: When running high speed (>9600 baud) communications, the system will hang intermittently. SOLUTION: Switch to buffered (16550) serial ports. On my system, I was able to move to 19200 baud with no hangs by switching to the buffered ports. You may also try setting "Optimize Communications" to Y in the DesqView Setup area. Be cautious with this setting as it can cause some problems as well. It is also helpful to upgrade to DesqView 2.26 as there is better support for high speed communications. NOTE 1: I have now gone to 38400 baud on my system using the X00 FOSSIL driver. Things seem to be operating smoothly. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 3 │ └───────────────────────┘ PROBLEM: When I do a print screen in DesqView 2.26, my computer hangs. SYMPTOMS: Pressing the print screen key while using DesqView 2.26, part of the screen will print and then the computer hangs up. Even CTRL- ALT-DEL will not reset the machine. SOLUTION: DesqView 2.26 uses a different method to do a printscreen. There is a patch available to change back to the old way of doing it. Patch your program and the problem will go away. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 4 │ └───────────────────────┘ PROBLEM: System hangs when using PCTools Deluxe Version 6 within DesqView. SYMPTOMS: If you try to delete multiple files with PCShell, the system will hang after deleting the first or second file. Sometimes you will be able to get to the DesqView Menu, but you will get an error message when you try to open another window. SOLUTION: The problem seems to be isolated to the Delete Tracking option of Mirror. You may use Mirror, but do not use the Delete Tracking Option. NOTE 1: Some additional information on this problem. When you use mirror with the delete tracking option, mirror sets up a TSR. This TSR is what gives DesqView fits. When you just use mirror without delete tracking, no TSR is needed. So mirror works fine without delete tracking. NOTE 2: Central Point has released a new version of mirror that is compatible with QEMM and DesqView even when using the delete tracking option. You may now also safely load the delete tracker high. I have verified that the new mirror does work as advertised. This file is available on The Bertha BBS as PCTOL6UD.ZIP. Quoting from the update readme file: Older versions of Mirror tried to process the system areas of the hard drive each time they were run. For this reason they weren't able to be loaded high in most cases. There just wasn't enough contiguous high memory available. The new version of Mirror solves this problem, but it requires you to load Mirror in a slightly different way. If you load Mirror like this now: MIRROR C: /TC and wish to load it high with QEMM you will need to change it to: MIRROR C: C:\QEMM\LOADHI C:\PCTOOLS\MIRROR /TC If you load Mirror as: MIRROR C: D: /TC /TC you will change it to: MIRROR C: D: C:\QEMM\LOADHI C:\PCTOOLS\MIRROR /TC /TD ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 5 │ └───────────────────────┘ PROBLEM: I can't get a caching program to work properly with DesqView. SYMPTOMS: After loading PC-Cache version 6, the cache does not work if you enter DesqView directly. If you use manifest to look at First Meg Programs, PC-CACHE is not listed. SOLUTION: I was not able to get PC-Cache version 6 to work correctly on my system. Either switch back to version 5.5 or get a shareware copy of ADCACHE. ADCACHE was written with QEMM, 386-to-the-max, and DesqView in mind. It is fast, small, and compatible. NOTE 1: I have also used Super PC-Kwik with success. It is larger than ADCACHE, but it is somewhat faster. NOTE 2: Central Point has released a new version of PC-Cache. This file is available on The Bertha BBS as PCTOL6UD.ZIP. I have not tried the new version because I had previously switched to Super PC-Kwik. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 6 │ └───────────────────────┘ PROBLEM: I can't seem to get enough high ram to load all the things I want to load high. SYMPTOMS: Insufficient high ram available to load applications. SOLUTION: If you have a color system (EGA/VGA) and never use monochrome, use the I=B000-B7FF switch on QEMM to include the monochrome video area. This will gain you 32K of high ram. NOTE 1: If you have a monochrome system and never use color, you may use the I=B800-BFFF switch on QEMM to include the color video area. This too will gain you 32K of high ram. NOTE 2: Newer versions of QEMM are better at automatically including these unused video areas. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 7 │ └───────────────────────┘ PROBLEM: Other DesqView windows operations grind to a halt when using a communications program in the foreground. SYMPTOMS: Severe performance degradation when using a communications program in another window. SOLUTION: Use Tame on your communications program to make it release the clock-ticks it doesn't need. It made about 400 cps difference on my system. NOTE 1: Tame 2.30 has its defaults set differently than 2.20. This means that you may have to fine tune it to work correctly. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 8 │ └───────────────────────┘ PROBLEM: I can't get enough memory freed up to open the size windows that I need to run my applications. I use Zenith Dos. SYMPTOMS: Window sizes are difficult to get above 460K due to the overhead of DOS, Video, Drivers, Etc. SOLUTION: If you are using Zenith Dos 3.3+, switch to Zenith Dos 4.01. Dos 4.01 is about 40K smaller than the later versions of 3.3+. That made my windows about 20K larger than before, leaving me more room to increase the size of my transmit and receive buffers. IBM Dos 4.01 is supposedly larger than 3.3, but Zenith Dos 4.01 is smaller. Zenith Dos 4.01 also appears to be free of most of the bugs in IBM Dos 4.01. NOTE 1: Different versions of Zenith Dos 3.3+ were different sizes. For example, doing a plain hard drive boot with no Autoexec.Bat and Buffers=8, Files=20 in Config.Sys the amount of memory remaining is as follows: Dos 3.30 / 3.30.08 (599,600 free) Dos 3.30 / 3.30.14 (562,064 free) Dos 4.01 / 4.00.02 (590,336 free) The later versions of Dos 3.3+ appear to be larger. I upgraded from Dos 3.30 / 3.30.14 to Dos 4.01. I gained about 28K with the upgrade. If you have an earlier version of Dos 3.3+, you may not benefit. To see what version of Dos you have, type VER from the dos prompt. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 9 │ └───────────────────────┘ PROBLEM: I am still fighting for larger windows and more high ram. I use a Zenith computer with a Zenith/DTC Hard/Floppy controller. SYMPTOMS: There is not enough free high ram to get the DesqView windows as large as I want to. SOLUTION: If (and only if) you use a Zenith computer with a Zenith/DTC controller, you may be able to include part or all of the C800-CFFF range to use as high ram. Zenith/DTC controllers normally do not have a BIOS on them. Disk I/O is handled by the Zenith BIOS. As a result you can use I=C800-CFFF on your QEMM line in order to gain another 32k of high ram. This should help your window size as well. Beware of other cards that may reside in that space. You may have a SCSI card there or something else. To make sure, use Manifest to see if there is anything in that space. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 10 │ └───────────────────────┘ PROBLEM: I get intermittent "weird" things that happen to my computer when I run DesqView. SYMPTOMS: Sometimes the system will "hang", other times it will do strange things. SOLUTION: I have heard of a number of problems being solved by using the NOSORT (NS) switch in QEMM 5.0. QEMM normally "sorts" the memory in your machine by speed. Some programs have a problem with memory that has been "sorted" by QEMM since the memory may not be contiguous. I use this switch with no problems, but cannot verify that it solved anything. NOTE 1: You should use the NS switch in QEMM if you intend to run Windows 3.0. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 11 │ └───────────────────────┘ PROBLEM: I get a "Drive x Not Ready" error message from my hard disk. SYMPTOMS: When doing disk intensive work in an application, a "Drive x Not Ready", "Abort, Retry, Fail?" error message will occur. By typing "R" to retry, the program continues normally until the next occurrence. SOLUTION: This error message occurs primarily with IDE drives, although any 1:1 interleaved drive may be affected. The problem is in the overhead that QEMM requires to operate. This is a problem that Quarterdeck has finally been able to reproduce, and they are working on it. If you do not have an IDE drive, you may be able to reformat you hard disk to 2:1 or 3:1 interleave. This will cause the drive and controller to be less timing critical. For an IDE drive, this is not possible. Some drives allow you to change a jumper on the drive to emulate 2:1 interleave. It is unclear whether this works or not. I have not tried this method. There are also some timing problems with some BIOS's. An upgrade to the most current revision might help the problem. Quarterdeck also suggests using Stacks=0,0 to reduce the DOS overhead. This promises to be an ongoing battle. Stay tuned... NOTE 1: If you have a machine with AMI Bios, you might try the following: In the advanced setup there is an entry called "16-bit AT command delay 00 00 01 01". Change this to "00 01 01 01". This is supposed to completely solve the IDE timeout problem. I haven't verified this, since I don't have a machine with AMI Bios. NOTE 2: The above problem is actually caused by a bug in most, if not all BIOSes. Problems have been reported in AMI, Award, and Phoenix BIOSes. I can report that I have had this problem with DTK's BIOS as well. The problem stems from the fact that some BIOSes initiate disk activity and then clear the "Interrupt Occurred" flag before checking for the incoming interrupt. In this case, any interrupt which has come in before the flag was cleared will not be processed and will result in a "Drive Not Ready" error message. Another problem is that some BIOSes lose interrupts during multi-sector reads. Quarterdeck has identified the problem and has a fix in the works. It probably won't pay to upgrade your BIOS to try to solve this problem as the BIOS makers are not aware that the problem exists. NOTE 3: Quarterdeck has released a fix for this problem. The program is called FIXNRE.COM. This is a TSR that should correct the bug that exists in a number of BIOSes. There is also a program called GENNRE.COM which attempts to generate a not ready error on your machine. Both programs are included in a ZIP file called FIXNRE.ZIP. This file is available on The Bertha BBS. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 12 │ └───────────────────────┘ PROBLEM: System hangs and file corruption occur when running under DesqView. SYMPTOMS: Intermittent system hangs when operating with DesqView. Sometimes files will be corrupted. Usually unable to reproduce the problem consistently. SOLUTION: Check your interrupts! Interrupt conflicts can cause all sorts of strange problems. I still see people recommend using IRQ2 on an AT class machine. IRQ2 is a cascaded interrupt for IRQ8 through IRQ15 and cannot be used. A lot of us upgraded from an XT and are used to setting our systems up to use IRQ2. I moved my bus mouse card from an XT to an AT and had all sorts of problems until I changed the interrupt from IRQ2 to something that was not being used. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 13 │ └───────────────────────┘ PROBLEM: How do I set up caching under DesqView? Is it different than under DOS? SYMPTOMS: Improper caching setup under Desqview can introduce many unwanted side-effects. These include slow operation, file corruption, and hangs. SOLUTION: The most important thing is to choose the right caching program. My recommendation would be Super PC-Kwik. From my own experience, this is the fastest and most compatible of the caches. I have also used ADCACHE and PC-Cache 5.5 with success. I have not been able to get PC-Cache 6.0 to work reliably. At this point, I would not recommend PC-Cache 6.0. A cache works by buffering information read from the hard disk into memory. Then when a read request comes along, the memory is checked for the information. If it is in memory already, the information is transferred without any hard drive activity! Since memory is much faster than any hard drive, the system operates faster. Some of the newer caches such as Super PC-Kwik, ADCACHE, and PC-Cache 6.0 also offer a feature called "Write-Caching". This allows the cache to buffer disk writes as well as disk reads. Under DesqView, this feature should be turned off. Otherwise DesqView could terminate an application without the cache being flushed first. If your machine ever hangs, you may suffer file corruption. Always load the cache before DesqView. I also recommend running your cache under Expanded (EMS) memory. Although EMS is slightly slower than Extended, there are less problems with interrupt latency when running in EMS. If you are doing any communications from within DesqView, use EMS, not extended. My parameter line to invoke Super PC-Kwik is as follows: SUPERPCK /A+ /S:3000 /H- /D- /T:8 /P- /-A /-B /-M /-N This sets up Super PC-Kwik to: use expanded memory (/A+), 3 megabytes (/S:3000), disable write caching on the hard drive (/H-), disable write caching on the floppy drives (/D-), buffer 8 sectors (/T:8), don't display the parameters at bootup (/P-), don't buffer floppy A: or B: (/-A /-B), and don't buffer the RAM drive or CD-ROM (/-M /-N). The /T:8 parameter may need a little more explanation. When an application requests a disk read, most caches allow you to specify how much of the rest of the track to read in to the buffer. Super PC-Kwik defaults to reading the entire track (/T+). Normally this is okay, but in my case I have an ESDI drive which claims to have 63 sectors per track. When an application requested a disk read on my system, the cache would read in the rest of the track, up to 63 sectors! This actually caused a reduction in the effectiveness of the cache. On MFM drives with 17 sectors per track, you may be able to use the defaults, but on RLL or ESDI drives, you are better off reducing the number of sectors to read in. You can experiment with different settings by using the parameters option and trying different settings. With enough memory and the proper settings it is possible to get "hit rates" greater than 90%. My system typically runs about 93% or more. Although I have detailed the settings for Super PC-Kwik, the concepts are similar no matter what cache you use. Another often overlooked benefit of caching is that you can reduce the number of DOS buffers needed. Usually you can set BUFFERS=4 or BUFFERS=6 in your CONFIG.SYS. This helps to regain some of the memory lost by the cache program itself. You can usually load the cache into high RAM if you have enough room. I have successfully loaded Super PC-Kwik, ADCACHE, and PC-Cache 5.5 high. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 14 │ └───────────────────────┘ PROBLEM: CD-ROM Drive does not work properly when using DesqView. SYMPTOMS: The system hangs after a CD-ROM access. Sometimes the system will run a long time between crashes and other times it won't. SOLUTION: CD-ROM systems can give DesqView fits. More accurately, QEMM is usually the culprit. All CD-ROM systems that I am aware of use the SCSI interface. SCSI cards use a technique called "bus mastering" in which the interface card actually takes control of the bus to do its transfers. This is bad news when running under a multitasker. There is a new SCSI specification which addresses this problem, but it is not in the "real world" yet. In the meantime, here are some things to try. The first thing to do is to make sure that you have no interrupt conflicts. This is important! The CD-ROM system that I use is a Toshiba XM-3201B. It uses a Future Domain 8-bit SCSI controller. The card comes configured from the factory to use IRQ3. This is also used by COM2 so if you are using COM2 you will have to change to another IRQ. Unfortunately, the only other choice on this card is IRQ5. IRQ5 is normally used by LPT2, but my system had a bus mouse which used IRQ5. The mouse had to go! The second thing to remember is that SCSI cards require some address space. Don't rely on QEMM to automatically find where your SCSI card is. Specifically exclude the area that it needs. Even Manifest will not locate what addresses are required. I set my card to use C800-C9FF and then told QEMM to exclude C800-CBFF. That may sound odd, but it works. For some reason, the SCSI driver likes to write to the CB00 area no matter where you set the address on the card. If you have something loaded into that area, you are going to crash. If you stay with the default address of CA00, I would suggest excluding CA00-CDFF. The key seems to be to allow 16k of memory above the address, no matter where you locate the card address. NOTE 1: The Future Domain SCSI controller has 6k of ROM, and uses 2k of RAM in the following manner: BASE ROM RAM HARDWARE I/O C800 C800:0000 - 17FF C800:1800 - 1BFF C800:1C00 - 1FFF CA00 CA00:0000 - 17FF CA00:1800 - 1BFF CA00:1C00 - 1FFF Total address space required: C800 BASE = C800 - C9FF CA00 BASE = CA00 - CBFF The RAM used for this card consists of 1k of RAM for local variables and a buffer area. The HARDWARE I/O area contains two memory-mapped hardware registers for the actual I/O, one for control and one for data. These registers are incompletely decoded, so they appear at all addresses in the 512 byte range. That is why Manifest and other programs have difficulty finding them. NOTE 2: I have successfully used the 8K exclusion on my BBS system for about a month. I have had no problems related to reducing the QEMM exclusion to 8K. This also gains another 8K of high ram. The QEMM command line for this machine looks like this: DEVICE=C:\QEMM\QEMM386.SYS ON NCF NR NS NW3 DMA=64 DB ...=4 TA=20 AROM=C800-C9FF ROM=C000-C7FF RAM My manifest printout for this machine looks like this: n=0123 4567 89AB CDEF █ + = Mappable 0n00 XXXX XXXX XXXX XXXX █ * = Rammable 1n00 ++++ ++++ ++++ ++++ █ F = Page Frame 2n00 ++++ ++++ ++++ ++++ █ H = High RAM 3n00 ++++ ++++ ++++ ++++ █ M = Mapped ROM 4n00 ++++ ++++ ++++ ++++ █ X = Excluded 5n00 ++++ ++++ ++++ ++++ █ V = Video 6n00 ++++ ++++ ++++ ++++ █ A = Adapter RAM 7n00 ++++ ++++ ++++ ++++ █ R = ROM 8n00 ++++ ++++ ++++ ++++ █ / = Split ROM 9n00 ++++ ++++ ++++ ++++ █ An00 VVVV VVVV VVVV VVVV █ Bn00 HHHH HHHH VVVV VVVV █ Cn00 MMMM MMMM RRHH HHHH █ Dn00 HHHH HHHH HHHH HHHH █ En00 FFFF FFFF FFFF FFFF █ Fn00 RRRR RRRR RRRR RRRR █ The third thing to do is to use the DISKBUF (DB) switch for QEMM. I use DB=4 on my system. This helps QEMM to handle the special way in which SCSI devices access memory. I have had success in loading FDCD.SYS and MSCDEX.EXE high. I use the /E switch on MSCDEX to tell it to use expanded memory. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 15 │ └───────────────────────┘ PROBLEM: Problems when running RBBS-PC under DesqView. SYMPTOMS: The RBBS-PC software will halt with an error message, although the computer is usually not hung. Sometimes the error message "press any key to return to system" will appear. If a key is pressed, the program recycles without incident. SOLUTION: I ran into this problem several times before I figured out what was happening. Most of us use DesqView because we can move and modify files even though the BBS is running. The thing we overlook is that RBBS-PC maintains several open files during its execution. If we modify a file that RBBS has open, we will get an error in the form of a "share violation". RBBS can't figure out what happened, so it halts execution. There are several things to do which will help to eliminate this problem. The first is simply to not modify files which are currently open by RBBS-PC. Be especially cautious about modifying files when a user is on-line. You don't really know what files the user may have open at any given time. The second thing is to switch to 4DOS and use SHARE.EXE. This enables file sharing and locking to handle this sort of problem. The last thing to do is invoke DesqView with the /DT switch. This allows DOS to terminate all programs rather than letting DesqView do it. I have noticed that if you let DesqView terminate programs, some files will not be closed properly. This can cause problems as well. I have implemented all these methods on my board and have not had a problem since. Remember that a multiple node BBS under DesqView is similar to a network. The same precautions that you would take in a network environment should be taken when running under DesqView. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────┐ │ QEMM/DesqView TIP# 16 │ └───────────────────────┘ PROBLEM: System hangs after doing floppy access. SYMPTOMS: The system will lock up after doing floppy access. This is not consistent, but usually occurs after writing to the floppy. Floppy reads do not seem to be a problem. SOLUTION: I noticed this problem with some regularity on my system. I got to the point where I realized that the hang was only occurring after a write to the floppy. Reads did not appear to trigger the hang. I was using PCTools 6.0 to move files from the floppy to the hard drive. After a file is copied, it is deleted from the floppy in order to complete the move. During this process, a hang would sometimes occur. This could be exacerbated by ejecting the floppy prematurely to cause an error. My system would hang in the middle of this error message. The solution to this problem was to be found in the command line for my cache. I use Super PC-Kwik. I had set up the cache to ignore drives A and B with the /-A and /-B switches. But when I looked at the parameters for the cache I realized that diskette writes were still enabled (/D+). I changed the command line to disable diskette writes (/D-) and the problem has not occurred since. It is unclear whether this is a problem on other caches. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌────────┐ │ Zenith │ └────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 1 │ └────────────────┘ PROBLEM: System hangs when using QEMM 5.0 and doing a warm boot on Zenith machines. SYMPTOMS: When requesting a CTRL-ALT-DEL reboot, the system hangs. You must then power down to reset. SOLUTION: Use the NOROM (NR) switch in QEMM 5.0. QEMM normally maps one 4k segment of the BIOS rom in order to detect reboots. Because of the way Zenith handles reboots, you must defeat this with the NOROM switch. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 2 │ └────────────────┘ PROBLEM: Video seems slow after installing QEMM 5.0 on Zenith machines equipped with Z-549 or Z-449 video cards. SYMPTOMS: Screen update speed is very slow. When you run a benchmark the BIOS video speeds are very slow. SOLUTION: Zenith normally maps the VGA and EGA roms to RAM in order to speed up their access. Compaq does things similarly, but not identically. You must use the NOCOMPACFEATURES (NCF) switch to defeat this. Your video should return to the correct speed. You must also exclude C000-C7FF and E000-E7FF with the X=C000-C7FF and X=E000-E7FF switches in order to make room for the video slush area. NOTE 1: If you have a Zenith Z-449 EGA card, you need to exclude C000-C3FF. You must still exclude E000-E7FF. NOTE 2: The C000-C7FF exclusion may not be necessary when using QEMM 5.0, 5.1, and 5.11. Newer versions of QEMM normally do not try to use the C000-C7FF area. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 3 │ └────────────────┘ PROBLEM: I can't get enough memory free to run the applications I want to run when using a Zenith computer and DesqView. SYMPTOMS: After setting up DesqView, my window size is limited to about 480K. Nothing I do seems to be able to raise it much above that. SOLUTION: There are two solutions that I have used with success. These solutions only apply if you have a Zenith 386 computer and a Z-549 VGA video card. NOTE 1: The following is a Manifest printout showing a standard QEMM installation with the following parameters: DEVICE=C:\QEMM\QEMM.SYS ON NCF NR X=E000-E7FF RAM n=0123 4567 89AB CDEF █ + = Mappable 0n00 XXXX XXXX XXXX XXXX █ * = Rammable 1n00 ++++ ++++ ++++ ++++ █ F = Page Frame 2n00 ++++ ++++ ++++ ++++ █ H = High RAM 3n00 ++++ ++++ ++++ ++++ █ M = Mapped ROM 4n00 ++++ ++++ ++++ ++++ █ X = Excluded 5n00 ++++ ++++ ++++ ++++ █ V = Video 6n00 ++++ ++++ ++++ ++++ █ A = Adapter RAM 7n00 ++++ ++++ ++++ ++++ █ R = ROM 8n00 ++++ ++++ ++++ ++++ █ / = Split ROM 9n00 ++++ ++++ ++++ ++++ █ An00 VVVV VVVV VVVV VVVV █ Bn00 HHHH HHHH VVVV VVVV █ Cn00 RRRR RRRR HHHH HHHH █ Dn00 FFFF FFFF FFFF FFFF █ En00 XXXX XXXX HHHH HHHH █ Fn00 RRRR RRRR RRRR RRRR █ Zenith normally "slushes" the Video ROM to E000-E7FF. A pointer is changed so that applications expect to find the ROM at that location. You can include the area from C100-C5FF with the I=C100- C5FF switch on the QEMM command line. This adds 20K of extra high RAM. Video speed is not affected by using this area, since the ROM has been slushed to the E000 area. NOTE 2: The following is a Manifest printout showing a QEMM installation which uses this modification: DEVICE=C:\QEMM\QEMM.SYS ON NCF NR X=E000-E7FF I=C100-C5FF RAM n=0123 4567 89AB CDEF █ + = Mappable 0n00 XXXX XXXX XXXX XXXX █ * = Rammable 1n00 ++++ ++++ ++++ ++++ █ F = Page Frame 2n00 ++++ ++++ ++++ ++++ █ H = High RAM 3n00 ++++ ++++ ++++ ++++ █ M = Mapped ROM 4n00 ++++ ++++ ++++ ++++ █ X = Excluded 5n00 ++++ ++++ ++++ ++++ █ V = Video 6n00 ++++ ++++ ++++ ++++ █ A = Adapter RAM 7n00 ++++ ++++ ++++ ++++ █ R = ROM 8n00 ++++ ++++ ++++ ++++ █ / = Split ROM 9n00 ++++ ++++ ++++ ++++ █ An00 VVVV VVVV VVVV VVVV █ Bn00 HHHH HHHH VVVV VVVV █ Cn00 RHHH HHRR HHHH HHHH █ Dn00 FFFF FFFF FFFF FFFF █ En00 XXXX XXXX HHHH HHHH █ Fn00 RRRR RRRR RRRR RRRR █ Note that the C100-C5FF area has been converted into high ram. The second solution is more elegant. There is a file on the Bertha BBS called UNSLUSH.ZIP. This file contains a device driver which changes the pointer back to the C000 paragraph and as a result does not use the E000-E7FF area. Video slushing still occurs, but since the pointer has been changed back to C000, the E000-E7FF area can now be mapped over with RAM by QEMM for its high RAM. The only problem is that BIOS video calls will be agonizingly slow. The solution is to have QEMM map the video ROM into RAM using the ROM=C000-C7FF switch. Your Config.Sys should contain the following: DEVICE=C:\UNSLUSHV.SYS DEVICE=C:\QEMM.SYS ON NCF NR ROM=C000-C7FF RAM This should give you an extra 32K of high RAM with no degradation of video performance. Note that you should include the NCF and NR switches on Zenith machines. These are explained in another area of this file. NOTE 3: The following is a manifest printout of this configuration: n=0123 4567 89AB CDEF █ + = Mappable 0n00 XXXX XXXX XXXX XXXX █ * = Rammable 1n00 ++++ ++++ ++++ ++++ █ F = Page Frame 2n00 ++++ ++++ ++++ ++++ █ H = High RAM 3n00 ++++ ++++ ++++ ++++ █ M = Mapped ROM 4n00 ++++ ++++ ++++ ++++ █ X = Excluded 5n00 ++++ ++++ ++++ ++++ █ V = Video 6n00 ++++ ++++ ++++ ++++ █ A = Adapter RAM 7n00 ++++ ++++ ++++ ++++ █ R = ROM 8n00 ++++ ++++ ++++ ++++ █ / = Split ROM 9n00 ++++ ++++ ++++ ++++ █ An00 VVVV VVVV VVVV VVVV █ Bn00 HHHH HHHH VVVV VVVV █ Cn00 MMMM MMMM HHHH HHHH █ Dn00 HHHH HHHH HHHH HHHH █ En00 FFFF FFFF FFFF FFFF █ Fn00 RRRR RRRR RRRR RRRR █ This configuration gives you very large contiguous regions of high ram. This is advantageous if you wish to load large TSR's into high ram. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 4 │ └────────────────┘ PROBLEM: When running PC Shell 6.0 on my Zenith system I get an "Unable To Read Sector" error message. The disk verifies fine with Diskfix or other utilities. SYMPTOMS: It appears that a file is bad when using PC Shells File Verify option. Usually this is noticed when copying a file from one area of the hard drive to another. However, when a surface scan is done, nothing is found. SOLUTION: On one of my systems the above problem which appeared initially as a hardware problem, turned out to be a problem with ADCACHE. I use ADCACHE on my BBS with no problems. For some (as yet unknown) reason, when I switched to a DTC ESDI controller and a 150 MEG drive, the problem appeared. ADCACHE was used successfully on the same machine with a DTC 7280 1:1 controller and 90 MEG drive. My solution was to switch to Super PC-Kwik. I am not convinced that the total problem was with ADCACHE, but I could not find any other problems with the machine. More to come... ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 5 │ └────────────────┘ PROBLEM: I keep getting an "Error, keyboard not responding or not connected" error message on my Zenith computer. SYMPTOMS: The above error message appears when doing a cold boot of the computer system. It may not happen all the time. It may occur with Zenith or clone keyboards. SOLUTION: The problem is in the keyboard reset circuitry. A look at the schematic for a Zenith ZKB-2 keyboard shows that pin 1 of the keyboard processor is used to provide a power-up reset to the processor itself. When power is first applies, capacitor C8 is totally discharged. This capacitor is charged through the keyboard processor towards five volts. Because of the capacitance, the charging is delayed and is held low long enough to provide the power-on reset. However, if the capacitor charges up too far towards five volts before the processor is ready, the reset signal is missed. A related factor may be the amount of memory and peripherals that you have in your computer. My problem surfaced after adding memory and a larger hard drive. It may be that the five volt supply does not come up as fast as normal due to the increased load. In my Zenith keyboard there is a 2.2 uf capacitor at C8. Electrolytics are notorious for changing their value dramatically with age. I also believe that raising the value from 2.2 to something in the 4.7 - 10 uf range would allow a much better chance for the keyboard processor to be properly reset. I also had a clone keyboard which would never be "seen" by the Zenith Z386-25 machine that I was using it on. This unit had a 4.7 uf tantalum capacitor on the processor reset pin. This had to be increased substantially in order for the keyboard to work properly. I went as high as 35 uf with no problems. The keyboard took a relatively long time to reset, but it worked fine, every time. If you do decide to replace the capacitor, observe proper polarity for either electrolytics or tantalums. If you are a hacker type, give it a try. Otherwise you can do what I did and order an upgraded BIOS, SCP, and then find out that a fifty cent part was giving you grief. NOTE 1: Originally it looks as if the computer was supposed to provide the reset signal for the keyboard, but in my ZKB-2 that jumper was not installed. My guess is that the reset signal is no longer supplied by the computer. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 6 │ └────────────────┘ PROBLEM: The hard disk on my Zenith Turbosport seems slow. SYMPTOMS: Access to the hard drive seems slow compared to what it should be. SOLUTION: There was a bug in the BIOS Rom of the Turbosport. This was fixed with ROM revision 444-651-3. Call Heath/Zenith parts and get an upgrade. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Zenith TIP# 7 │ └────────────────┘ PROBLEM: Problems interfacing the Irwin 445A tape backup unit. SYMPTOMS: The tape backup unit will work with some DTC/Zenith cards and not with others. SOLUTION: Make sure that you are using a 6280, 7280, or 7287 DTC/Zenith hard/floppy controller card. The 5280 will not work since it is missing some of the required support circuitry. On most cards it is necessary to add a 37-pin right-angle connector to the back panel. The proper tape cartridge is a DC-2000. The drive normally comes with EZ-Tape software, but I use PC-Backup 6.0 from Central Point. Because of the compression used by this program, I am able to get about 60 megabytes of data on one 40 megabyte cartridge. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌─────────┐ │ RBBS-PC │ └─────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 1 │ └─────────────────┘ PROBLEM: When I run RBBS-PC and someone does a download or upload, I can't open another DesqView window without interfering with their communications. I have replaced my UARTS with 16550's. SYMPTOMS: When a user on one node of RBBS-PC is uploading or downloading, opening another window will introduce CRC errors into their transmission. This occurs on the internal protocols (Xmodem, Ymodem, Ascii). SOLUTION: This is a very obscure problem which does not have an obvious answer. The problem is that RBBS-PC by itself does not initialize the 16550 chips. Therefore the internal protocols do not benefit from the buffering. External protocols such as Zmodem, YmodemG, and others have a program such as DSZ to initialize the 16550. The solution is to use a fossil driver such as X00 to initialize the 16550 chips. This will make them available to the internal protocols as well. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 2 │ └─────────────────┘ PROBLEM: The performance of RBBS-PC seems slow when using two or more nodes under DesqView. SYMPTOMS: The BBS seems to be slow in doing file accesses, screen updates, etc. SOLUTION: There are several things which can be done to improve the performance of RBBS-PC under DesqView. You must be fairly well versed in DOS, RBBS, and DesqView/QEMM in order to accomplish your goal effectively. Remember that DesqView splits up your computer resources among the applications that you have opened. The more efficiently that your computer operates, the more resources will be available to your programs. 1. Use a cache. This makes a big difference in disk access. I use ADCACHE on my board. The cache sits in expanded memory and is 2 megabytes. I get track hits of about 95 percent. That saves a lot of time when trying to do several things at once. Do NOT use write caching, especially under DesqView. If you use write caching, you may corrupt your FAT. If you use a fairly large cache, you should be able to reduce the size of your DOS buffers. I use Buffers=4 in my Config.Sys. This increases the available memory to your system. I do not recommend loading buffers high or using Quarterdeck's Buffers.Com. I have heard of some strange things happening for those who do. NOTE 1: I have switched to Super PC-Kwik Cache. It is faster than ADCACHE and seems to be aware of more hardware and software combinations. I have also increased the size of the cache to 3 megabytes. 2. Use a ramdisk. Some of the RBBS files may be put in a ramdisk. This allows very fast reads of the files that do not change during a session. I use Zenith's VDISK and set up a 1 megabyte ramdisk. I use a batch file to copy all of my menus and my working directories into the ramdisk. You must modify RBBS using CONFIG to reflect the new location of these files. 3. Use a FOSSIL driver. This is important when using high speed communications. I use X00.SYS on my board since it recognizes DesqView with the DV switch. I set up my Dual Standard or HST modem to communicate with the computer at 38400 baud. You can't go faster than 19200 without using a FOSSIL driver because RBBS does not support it. You will probably run into problems unless you have 16550 buffered chips also. I have increased my X00 transmit and receive buffer sizes to 4096 bytes each. The default is 1024 bytes. This allows more effective utilization of the clock ticks that each window gets. You may be able to increase them more depending on how much base memory you have available. 4. Set "Dos Buffers For EMS" to 0 in the DesqView setup if you are not running on a network. This setting made no difference when I was using ADCACHE, but made a considerable difference when using Super PC-Kwik. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 3 │ └─────────────────┘ PROBLEM: I am having trouble getting X00.SYS to work properly. SYMPTOMS: X00 is difficult to setup to achieve optimal performance. SOLUTION: X00 works very well, but can be difficult to setup properly. You need to use a fossil driver in order to use a baud rate higher than 19200. I use X00 to enable my ports to run at 38400 baud. My command line is as follows: DEVICE=C:\RBBS\FOSSIL\X00.SYS E 0=3F8,IRQ4 1=2F8,IRQ3 B,0,38400 B,1,38400 T=4096 R=4096 DV F=15 This command line can be commented as follows: DEVICE=C:\RBBS\FOSSIL\X00.SYS (Calls X00.SYS from my subdirectory) E (Eliminates the sign-on screen from X00) 0=3F8,IRQ4 (Sets up first serial port at 3F8 and using IRQ4) 1=2F8,IRQ3 (Sets up second serial port at 2F8 and using IRQ3) B,0,38400 (Locks first serial port at 38400 baud) B,1,38400 (Locks second serial port at 38400 baud) T=4096 (Sets transmit buffer to 4096 bytes) R=4096 (Sets receive buffer to 4096 bytes) DV (DesqView pause which releases clock ticks when idle) F=15 (Sets 16550 FIFO to 15 bytes rather than default of 8) NOTE 1: Newer versions of X00 have bug fixes along with better performance with DesqView. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 4 │ └─────────────────┘ PROBLEM: Some callers have trouble connecting to my board. I use a USR Dual Standard or HST modem. SYMPTOMS: Most callers have no trouble connecting, but some callers have to call several times before they can get connected correctly. Some callers have trouble with MNP error correction working correctly. Other callers have trouble with getting disconnected in the middle of their session. SOLUTION: This sort of problem has many causes and solutions. There are many types of modems out there and some are better than others. Many problems can be solved by changing S-register settings, but others can't. Telebit modems are particularly troublesome since they send a special set of tones to alert the other modem that they are a Telebit. These tones can confuse USR modems. The first thing to do is to make sure that your modem is handshaking properly and your software is set up properly. It is always easy to blame someone else for your troubles. If your setup is okay, then try the following suggestions: S28=0 Use this setting if some of your 2400 baud users have trouble connecting to the board. This S-register sets the duration of the V.32 answer tones. These tones allow quick connects in V.32 mode. However, the tones also confuse some modems. This does not disable V.32 modulation. The default is 8. USR is recommending 0. If some of your other users have trouble you can try 2 or 4. S15=64 Use this setting to help with MNP-5 problems. Some earlier 2400 baud MNP modems were not fully compatible with the MNP protocol. Setting this S-register to 64 enables non- standard MNP compatibility. S15=8 Use this setting if users have trouble with characters over-running their screens when an X-OFF is issued. This can also occur when file transfers crash or abort in the middle of a download. Then they get a whole screen full of garbage because the modem keeps sending until its buffer is cleared. Setting this register to 8 reduces the size of the buffer to 128 bytes from its default of 1.5k bytes. This change only occurs during non ARQ connections. S15=72 Use this setting to incorporate both of the above changes. S10=10 Use this setting if you have a number of callers who call in with call waiting. Call waiting is a real problem for people who run a BBS. When a call is coming in on the callers phone, the line is momentarily disconnected. Sometimes the modem on the BBS will react by detecting the loss of carrier and will disconnect. You can reduce the chance of this happening by setting this register to 10 or more. Of course, sometimes the calling modem will disconnect. You have no control over that. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ RBBS-PC TIP# 5 │ └─────────────────┘ PROBLEM: Zmodem giving error messages during uploads/downloads. X00.SYS does not seem to handle Zmodem transfers as well as it does Xmodem or Ymodem transfers. SYMPTOMS: Zmodem will output error messages such as "Serial Input Error: Line Status Register 02" during uploads or downloads. SOLUTION: File transfer protocols such as Zmodem and Ymodem-G are "External Protocols", meaning that in order to use them RBBS must shell to DOS and invoke an external protocol driver such as DSZ. Unfortunately, DSZ does not currently have fossil support. As a result, X00.SYS does not benefit DSZ or any of its protocols. The solution is to press Chuck Forsberg to implement fossil support into the DSZ engine. As modem speeds rise and more sysops run DesqView, the need for fossil support becomes even more apparent. In the meantime, avoid using large buffers for DSZ. Work to increase the speed of your system through the use of caching and ram disks. By decreasing the amount of time it takes to do disk access, you run less risk of being late in servicing an interrupt. Also, setting your DesqView Foreground/Background clock ticks to small numbers close together (3-3 or 2-2) will help improve interrupt latency due to task switching. If you still have problems, use the HANDSHAKE SLOW command to disable reception during disk transfers. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Communications │ └────────────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 1 │ └────────────────────────┘ PROBLEM: Connect problems when using MNP-5 modems. Sometimes the speed is slower than other times. SYMPTOMS: When calling a BBS that is using a U.S. Robotics Dual-Standard or HST modem using a 2400 baud MNP-5 modem, sometimes the connection will be at 2400 baud and sometimes it will be 1200. In both cases the connection will be a "reliable connect". SOLUTION: Some 2400 baud MNP-5 modems are not fully compatible with the MNP protocol. Generally these were earlier modems, but I know of one case where the modem was a current production model. The solution is to have the BBS operator change his S15 register to 64. This allows compatibility with these modems. This register change must be done on the Dual-Standard or HST modem, not on the 2400 baud modem. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 2 │ └────────────────────────┘ PROBLEM: Download speeds of ZIP files seem slow when using a 2400 baud MNP-5 modem. SYMPTOMS: When downloading from some BBS's the download speed of ZIP files is about 280 cps. From other boards only about 250 cps is possible. SOLUTION: MNP-5 compression is not effective on ZIP files. In fact, if you try to compress a ZIP file, things actually slow down. As a result, most boards disable MNP-5 compression. You can still achieve an error correcting link, but there will be no compression. Under this scenario you will achieve about 280 cps download speeds at the expense of screen update speed. The screens full of menus are not compressed either! On my board, MNP-5 compression is enabled. If you call in with MNP-5 your screen updates will be very fast, but your downloads of ZIP files will be in the 250 cps area. If you download Text or ASCII files, you may achieve rates as high as 500 cps. The solution is to defeat compression on the callers end when you want to download ZIP files. There is usually an "AT" command to defeat MNP-5 compression. Read your manual. If you intend to do a lot of downloading, defeat MNP-5. If you are just calling to browse, leave it on. You now have the best of both worlds. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 3 │ └────────────────────────┘ PROBLEM: Download speeds from some HST boards are not as fast as on other HST boards. SYMPTOMS: Download speeds from some HST boards run up to 1700 cps. Others can achieve only about 900-1100 cps. SOLUTION: U.S. Robotics manufactured two HST modems. The old modem was an HST 9600. The newer model was an HST 14400. The 9600 used a 9600 baud forward channel and a 300 baud back channel. The 14400 used a 14400 baud forward channel and a 450 baud back channel. After you sign off the board, do an ATI6. at the bottom of the screen you will see 9600/300 or 14400/450. This will tell you what type of modem you hooked up with. There are a lot of old HST's out there. There really is no solution to this problem unless you want to send your favorite SYSOP about $500.00 for a new HST. NOTE 1: It is possible that the SYSOP doesn't have his modem set up correctly, but I have found that to be somewhat rare. Normally that won't exact that much performance loss. If the SYSOP has an HST 9600 there really isn't much he can do. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 4 │ └────────────────────────┘ PROBLEM: DSZ/Zmodem refuses to work with my computer system. SYMPTOMS: When using DSZ/Zmodem, it refuses to recognize the serial port. No communication occurs and I get bumped out of the program. SOLUTION: I ran into this problem with DSZ/Zmodem on my machine. The problem is that I was using a non-standard Port/IRQ combination. My system uses COM3 and IRQ5 for the modem. In order to support this combination you must invoke DSZ with the portx parameter. My command line to invoke DSZ from Qmodem is as follows: DSZ portx 3e8,5 speed %1 rz -rr This sets up DSZ to use COM3 and IRQ5. DSZ is case sensitive! Do not use upper-case letters for parameters. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 5 │ └────────────────────────┘ PROBLEM: I get garbage characters on my screen even though I have an MNP-5 modem. SYMPTOMS: Strange characters appear on the screen when using a communications program. This occurs randomly whether typing or not. SOLUTION: Make sure that MNP-5 is turned on. Some modems will not allow you to defeat compression without also defeating error correction. On zipped files, throughput suffers because of MNP-5. However, if you turn off MNP-5 you may lose error correction. Check your manuals. U.S. Robotics Dual-Standard and HST modems allow the defeating of MNP-5 compression while still maintaining an error correcting link. Other modems may not be as flexible. Also, check to make sure that the remote modem is also MNP-5 capable. If the other modem doesn't have MNP-5 you won't get an error correcting link. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────────────┐ │ Communications TIP# 6 │ └────────────────────────┘ PROBLEM: Unable to attain a V.42bis connection with USR modem. SYMPTOMS: Even though I have a V.42bis modem, I can't connect to a remote V.42bis modem properly. I just get a normal MNP-5 connection. SOLUTION: In order for V.42bis to work properly it has to be enabled on both ends. With a U.S. Robotics HST or Dual-Standard you must send AT&A3 and either AT&K1 or AT&K3 in order to turn compression on. Some BBS's turn compression off so a V.42bis connection is impossible. Another potential problem is that you must have your com port locked at 38400 baud in order for V.42bis to work. Since V.42bis uses 4:1 compression you must send data to the modem at 38400 in order for it to be effective anyway. A V.42bis connection between two HST's can transfer text at some pretty amazing speeds. I have heard of speeds as high as 3200 cps and I have seen transfer speeds on my system as high as 2850 cps on text files. The best thing about V.42bis is that there is virtually no penalty for ZIP transfers. You end up with the best of both worlds. The menus and other text really fly by and there is no degradation when transferring ZIP files. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌─────────┐ │ Doorway │ └─────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 1 │ └─────────────────┘ PROBLEM: When I use Doorway to drop to dos, the screen for applications such as PC Shell is not right. This problem only occurs when running two or more nodes of RBBS-PC under DesqView. SYMPTOMS: When doing a remote drop to dos and using a "mis-behaved" program such as PC Shell, half of the screen is black. Sometimes the screen of another node will be seen remotely. SOLUTION: Set the "Virtualize text/graphics" to "Y" in the DesqView setup for each node of RBBS-PC. Normally RBBS-PC does not require this since it does not do direct screen writes. However, when you run a program remotely using doorway, all of the programs you run may not be "well-behaved". By telling DesqView to Virtualize everything, you will force the program to behave itself, even in a door. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 2 │ └─────────────────┘ PROBLEM: Typing during a screen update will produce garbage characters. SYMPTOMS: During a remote screen update, if a character is pressed, the screen will be jumbled up. If you wait until after the screen has been updated, everything works normally. SOLUTION: There are two things which I have done to eliminate this problem. The first is to make sure that the FIFO of the 16550 on the BBS is enabled to 15. I use X00.SYS on my system. The default FIFO initialization is 8. You must use the F=15 switch to enable 15 bytes of buffering. Use this switch with caution as it increases interrupt latency. If you have problems with uploads or downloads, go back to the default setting. The second thing which seems to help is to use XU to enable the Fossil before running Doorway. My batch file looks like this: XU PORT:0:ON DOORWAY COM1F ... (Your Doorway switches go here) XU PORT:0:OFF The COM1F was added with Doorway 2.06Beta to allow use of a fossil driver, however it appears that Doorway cannot turn the fossil on and off by itself. When RBBS shells, it turns the fossil off. It then turns it back on when it resumes normal operations. By using XU to turn the fossil on, Doorway benefits from its use. After making these changes, I was unable to introduce any errors into my screen updates. If you do not have Doorway 2.06, I suggest that you upgrade. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 3 │ └─────────────────┘ PROBLEM: Some programs refuse to run remotely with Doorway. SYMPTOMS: Programs such as SHEZ, THEDRAW, UPDN, and FLASH will not run with Doorway. When I try to run them, I am returned either to the menu or to the board. Other programs such as PCSHELL and PFS Pro-Write run fine. SOLUTION: Some programs have to be executed from their own subdirectory. You need to use a batch file to change to that specific subdirectory. Unfortunately, you need Command.Com to execute batch files. Doorway will load Command.Com provided you use the /C:VIA switch. You need to create a batch file and invoke these programs using the /C:VIA switch as follows: /C:VIA /P:D:\UTILITY\SHEZ\DOORSHEZ.BAT /C:VIA /P:C:\THEDRAW\DOORDRAW.BAT /C:VIA /P:C:\RBBS\DOORUPDN.BAT /C:VIA /P:C:\RBBS\FLASH\DOORFLAS.BAT My batch file for SHEZ looks like this: D: CD\UTILITY\SHEZ SHEZ.EXE C: CD\RBBS\DOORWAY EXIT Since SHEZ is configured to run in a specific subdirectory, it should be invoked by a batch file and you need Command.Com to run batch files. NOTE 1: It is important to return to the Doorway subdirectory before exiting from your batch file. ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Doorway TIP# 4 │ └─────────────────┘ PROBLEM: PC Shell won't display proper characters under Doorway. SYMPTOMS: When running PC Shell (Version 5.5 or 6.0) under Doorway, ALT-H (Show) in the file editor will not display the highlited reverse arrow key. The screen gets all jumbled up and is virtually unreadable. SOLUTION: Get an updated version of Doorway 2.06 Beta. Marshall Dudley has corrected this bug in the later versions of 2.06 Beta. My version is dated 11-17-90. Beta versions of Doorway are available only to registered users. NOTE 1: Doorway version 2.11 has now been released. This file is available from The Bertha BBS. Doorway is shareware. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌────────┐ │ Qmodem │ └────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Qmodem TIP# 1 │ └────────────────┘ PROBLEM: Qmodem 4.2 or 4.2A will not dial phone automatically, although manual dialing works fine. This was not a problem with 4.1b. SYMPTOMS: After doing an ALT-D and trying to get Qmodem to dial the phone, nothing happens. The modem does not take the phone off-hook. SOLUTION: This can occur after upgrading from Qmodem 4.1b to Qmodem 4.2 or 4.2A. When you use 40TO42 to convert your .FON file to the new format, the prefixes are not converted since they are stored elsewhere. You need to re-enter your prefixes into 4.2 or 4.2A. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Qmodem TIP# 2 │ └────────────────┘ PROBLEM: ANSI codes appear randomly on screen with Qmodem 4.2. SYMPTOMS: When using Qmodem 4.2, 4.2A, or 4.2B, random ANSI codes will appear on the screen. This can be caused to occur by pressing keys in rapid succession while receiving a screen update. Qmodem 4.1b did not exhibit this behavior. SOLUTION: Set INT16 ENABLE To OFF. When ON, Qmodem uses an internal keyboard input handler which supports 101-key enhanced keyboards, including the F11 & F12 function keys. When OFF, Qmodem uses the standard DOS input handler and the F11 & F12 function keys are not supported. The machine I noticed this on was a Zenith 286/8MHZ. After changing this switch, I have had no further problems. ══════════════════════════════════════════════════════════════════════════════ ┌────────────────┐ │ Qmodem TIP# 3 │ └────────────────┘ PROBLEM: Random characters lost during BBS sessions. SYMPTOMS: During a BBS session, if a key is pressed when receiving data from the board, sometimes a character or two will be lost. The text will be shifted to the left by however many characters were missing. This normally happens on my system when I am receiving color menus from the board. If I press a key while the menu is being updated, portions of the menu will be missing or shifted over. SOLUTION: Get a serial card with 16550AFN UARTs. The 16550AFN has a 16 byte buffer to handle problems with interrupt latency. The standard serial port UART is either an 8250 or 16450. Neither of these chips has a buffer. Interrupt latency is usually not suspected in systems that are not multitasking, however I have seen this problem occur on 8 MHZ and 12 MHZ 286 systems with no multitasking software installed. Installing a buffered serial card totally solved the problem. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────┐ │ Reconfig/Automenu │ └───────────────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────────┐ │ Reconfig/Automenu TIP# 1 │ └───────────────────────────┘ PROBLEM: When I use Reconfig in combination with a cache, the configuration is not changed. SYMPTOMS: When Reconfig does a warm boot after changing the Config.Sys and Autoexec.Bat files, the changes are not made. The computer boots up with the old configuration. This only happens when using a cache. SOLUTION: This problem occurs because of "write caching". PC-Cache 6.0, ADCACHE, and Super PC-Kwik all use write caching which caches all disk writes as well as disk reads. PC-Cache 6.0 however has write caching as its default. On some machines, the warm boot will occur before the cache has written the changes to the disk. This may depend on the speed of the machine as well. The solution is either to disable write caching or to flush the cache before rebooting. I elected not to use write caching since Reconfig does not have a convenient place to flush the cache. Other programs may be different. NOTE 1: It is possible to use write-caching with Reconfig, although it is a bit involved. Please see Reconfig/Automenu TIP #2. ══════════════════════════════════════════════════════════════════════════════ ┌───────────────────────────┐ │ Reconfig/Automenu TIP# 2 │ └───────────────────────────┘ PROBLEM: I can't get write-caching to work with Reconfig or Automenu. SYMPTOMS: Reconfig won't save the changes when rebooting. Automenu works, but I am worried about data corruption when using write-caching. SOLUTION: Write-caching can be successfully used under a menuing system, even those that require occasional reboots to change system parameters and configurations. These reboots are normally required to remove TSR programs from memory so that programs have a "clean" environment to run in. I normally reboot to run PC-Backup, DiskFix, DesqView, Windows, and many other programs. Each has its own special drivers and configuration. By performing a warm boot, I don't have to worry as much about TSR conflicts. By being very careful, you can use write-caching without inordinate risk. Of course, if you get a power failure, or a hang, you will still be in trouble. If you are not technically versed in your hardware and software, you are better off backing out now. The first thing to do is to find a cache program that allows you to both flush and disable the cache from dos. I use Super PC-Kwik. Once Super PC-Kwik is installed, the command SUPERPCK /F flushes the cache, and SUPERPCK /D disables the cache until you enable it again with SUPERPCK /E. Other caches may have this capability as well. I will explain how I was able to use write-caching on my system. If you use a different cache you will have to figure out whether you can do the same. Those of us with menu driven systems normally have a menu option to QUIT. Sometimes there is also a head parking utility which is run at this time. If you use write-caching you MUST have a menu option to QUIT. The reason is that when you are ready to quit, you must flush the cache before you power down. With Automenu, just put the command SUPERPCK /F /D before your head parking utility and your cache will be flushed and disabled before you quit. If you have a menu option that calls a Reconfig configuration, put SUPERPCK /F /D before you call Reconfig. Make sure that the subdirectory that has SUPERPCK is pointed to in your PATH statement, otherwise your cache won't get flushed and disabled. Examples...Examples...Examples... *AUTOMENU* Comment │.│.............................................. Selection │*│QUIT (Flush Cache, Park Heads) Batch-NRes │+│CD\ Batch-NRes │+│SUPERPCK /F /D Batch-NRes │+│PARK Batch-NRes │+│SUPERPCK /E Batch-NRes │+│AUTO Comment │.│.............................................. NOTE 1: In this example the cache is flushed and disabled before parking the heads. If the user presses a key to return to the menu, the cache is enabled before returning. Some head parking utilities do not allow you to return, so the last two lines are not necessary. This concept may also be used to disable the cache before running some programs that will not report accurate information with a cache, although the cache will still be in memory. The best solution is to reboot the system with the new configuration. Comment │.│.............................................. Selection │*│PCTools Deluxe 6.0 Disk Fix Batch-NRes │+│CD\ Batch-NRes │+│SUPERPCK /F /D Batch-NRes │+│RECONFIG DISKFIX Comment │.│.............................................. NOTE 2: This example shows how to flush and disable the cache prior to executing Reconfig. When Reconfig boots the system with your normal configuration, caching will be enabled as usual. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌──────────┐ │ Hardware │ └──────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌──────────────────┐ │ Hardware TIP# 1 │ └──────────────────┘ PROBLEM: After installing a new hard or floppy drive, the unit doesn't work. I have checked my drive select jumpers and they are fine. SYMPTOMS: The floppy drive refuses to read disks, the hard drive acts like it isn't hooked up. SOLUTION: Check your cables! Zenith normally uses cables with no "twist". You then set the drive select jumpers to the physical location of the drive. Example: Drive A: would be DS0, and Drive B: would be DS1. IBM uses a cable which "twists" the drive select lines to fool the first drive. Example: Drive A: would be at the end of the cable and be DS1, and Drive B: would be before the twist and be DS1 also. If you are using "twist" cables which IBM likes to use, make sure you are using a cable with the proper twist. If you are like me, you didn't know there was a difference. IBM twists wires 25 through 29 for a hard drive cable and wires 10 through 16 for a floppy drive. Using the wrong cable can cause many problems. ══════════════════════════════════════════════════════════════════════════════ ┌──────────────────┐ │ Hardware TIP# 2 │ └──────────────────┘ PROBLEM: Two LPT ports will not work correctly on one machine. SYMPTOMS: When attempting to run two parallel printers on one computer, both printers respond to data from the LPT1 port. Port number 1 is set up as LPT1 and port 2 is set up as LPT2. Printing to LPT2 just hangs the machine, although a CTRL-C will break out. SOLUTION: Set your second printer port to LPT3 rather than LPT2. The reason is that DOS uses logical addresses to reference printers. DOS expects to find the first printer port at 3BC. This address is only used by the "Monochrome Display With Printer Adapter". If you don't have this particular card in your computer, DOS will designate the physical LPT2 port as logical device LPT1. The following chart will help show this: Printer Port BIOS DOS Address Reference Reference ------------ --------- ------------------------------- 3BC LPT1 LPT1 378 LPT2 LPT2 (LPT1 if 3BC is absent) 278 LPT3 LPT3 (LPT2 if 3BC is absent) ══════════════════════════════════════════════════════════════════════════════ ┌──────────────────┐ │ Hardware TIP# 3 │ └──────────────────┘ PROBLEM: Garbled characters when using an IBM 5182 color printer. SYMPTOMS: Characters (especially graphics) will get garbled when printing long documents on this printer. Another symptom will be printer not ready errors occurring at random intervals. SOLUTION: The IBM 5182 color printer uses a Centronics parallel interface. Pin 12 is used to signal "Page End" or "Paper Empty". The problem with this particular printer is that pin 12 is not connected to anything within the printer. It is just an open line! If you use a "standard" parallel cable with this printer, all of the wires are connected. When doing heavy printing, a spike may inductively couple into the wire connected to this pin and be interpreted by the computer as a "Page End" or "Paper Empty" signal. This causes the computer to believe that there is a problem and it halts with an error message. If an oscilloscope is placed on this pin you can actually see the inductive spikes! The solution is to ground this pin to eliminate the inductive spikes. It is likely that originally, the printer came with a special cable that did not have this wire connected. It is also possible that this wire was grounded within one of the connectors. Do NOT attempt this unless you are well versed in electronic maintenance. There are hazardous voltages within a printer. This will also void your warranty. If you are still game, this may be done as follows: Disassemble the printer and remove the interface board. You will see a ribbon cable that runs from the connector on the rear down to the board itself. On the solder side of the board, note that the lines are numbered. You need to jumper line 12 to ground. The easiest way that I found is to put a small jumper wire from line 12 directly across to line 30. Lines 19 through 30 are all grounded. 36 oooooo│ooooooooooo 19 │<-Jumper Solder Side 18 oooooo│ooooooooooo 1 This is an extremely well built printer and should work for a long time. This modification should make it work properly with any standard parallel cable. ══════════════════════════════════════════════════════════════════════════════ ══════════════════════════════════════════════════════════════════════════════ ┌─────────┐ │ Windows │ └─────────┘ ══════════════════════════════════════════════════════════════════════════════ ┌─────────────────┐ │ Windows TIP# 1 │ └─────────────────┘ PROBLEM: Windows 3.0 will not run when using Disk Manager. SYMPTOMS: When attempting to load Windows 3.0, the process will hang and the hard drive activity light will flash on and off at about 30 second intervals. Program Manager will not load. SOLUTION: When using Windows 3.0 with Disk Manager, you must turn off VirtualHDIrq in the [386enh] section of SYSTEM.INI. The proper format is: VirtualHDIrq=OFF The default for this switch is ON. Windows in 386 enhanced mode normally terminates interrupts from the hard disk controller, bypassing the ROM routine that handles these interrupts. This interferes with the way that Disk Manager's device driver handles disk access. ══════════════════════════════════════════════════════════════════════════════ The End.